fix(bench): give in-process its own drain byte cap - #179

Why

benches/results/bench-results.json on main holds six runs and 822 rows, and 99 of those rows are setup_bound — measured, but withheld from every chart. The largest single block is the in-process 64 KiB consume leg: at the matrix's 3 GiB cap that leg is 49 152 messages, and the 2026-09-08 run drained every one of the eleven cells in 0.09–0.46 s. All eleven fall under MIN_FRAMEWORK_WINDOW_SECS, so the harness marks them setup_bound and the charts withhold all eleven behind one caption line:

inmemory / parallel, batch: measured, but every window under 1 s — too short to publish as a rate, even a lower bound

Nothing false is published, but the fastest backend in the set contributes no 64 KiB consume rate at all.

Why not just raise the cap

Because 3 GiB is not a cautious number for the other five — it is the containerised limit. Every other backend stages its corpus inside the 8 GB Docker VM (Redis and NATS in container memory, Kafka through its page cache), where 3 GiB is already over a third of the VM and where a 3.2 GB backlog has already taken Redis down mid-pass — the reason --load-backlog-max-bytes exists at all.

A global raise also lands on a leg that does not need it: past ~5.7 GiB the 1 KiB leg stops being byte-bound and doubles to the pinned 6 M for every backend, which projects to about +45 min of drain wall clock (RabbitMQ's 1 KiB leg alone goes 25.8 → 49.1 min) to fix rows that already clear the floor.

In-process is the one backend that stages its corpus in the harness process on the 64 GB host and never starts a container. So its cap is the one that can rise.

What this does

Substitutes --drain-max-bytes for the inmemory target only, at 32 GiB — the mirror image of the SQS corpus deviation already in the script. SQS drains a smaller corpus because it is the only backend slow enough that the pinned count means something else there; in-process is allowed a larger one because it is the only backend fast enough that the pinned byte cap does. Both substitutions now go through one substitute_knob helper that still dies when its knob leaves the matrix.

32 GiB is 524 288 messages at 64 KiB. Projecting the measured rates onto that corpus:

Ten of eleven publish. The eleventh is the fastest cell in the document (514 k msg/s); clearing it too needs ~40 GiB, and MIN_FRAMEWORK_CORPUS_MESSAGES's own doc declines to chase a window that hardware speed keeps moving. It stays withheld and captioned, which costs one bar rather than the pass.

It moves the 1 KiB leg too, by design: 3 145 728 → the pinned 6 000 000, so in-process runs two of its three legs on the matrix's own corpus rather than one, and the single 1 KiB cell that drained in 0.97 s clears the floor. Cost: ~40 s and 6 GiB rather than 3 GiB resident. Peak resident is the 64 KiB leg at ~34 GB of 64 GB, with no container to share the host.

Verification

Argv, per backend — stubbed cargo/docker, ran the script:

• inmemory → --drain-messages 6000000 --drain-max-bytes 34359738368
• kafka, redis → both pinned values untouched
• sqs → --drain-messages 60000, byte cap untouched at 3 GiB, --fifo-messages 100

The guard fires — removed --drain-max-bytes from MATRIX and re-ran inmemory:

bench.sh: the matrix has no --drain-max-bytes for the inmemory deviation to replace

Refusal gate cleared — refused_drain_capacity would refuse a corpus above the backend's declared queue capacity. QUEUE_CAPACITY is 8 000 000 and is a bound rather than a preallocation, so 524 288 clears it. The byte cap can only ever lower the corpus below --drain-messages, so 8 M bounds any cap value.

Rendering control — projected that corpus onto the committed six-backend document (respecting the validator's drain derivations) and ran chartgen. It renders every family at exit 0. The caption drops the "every window under 1 s" note and gains a two-line group:

corpus differs by backend: inmemory 524k; kafka, nats, rabbitmq, redis, sqs 49k — a smaller corpus is a shorter window, not a different measurement

The parallel-vs-sequenced-64kib canvas goes 672 → 688 of the 768 that MAX_CAPTION_GROWTH_LINES (8) allows, so three of eight growth lines are spent and five stay spare. Every other family stays on the base 640. This is the "wider corpus deviation" #178's budget test anticipated, and it seats inside the allowance.

Suite — cargo nextest run --no-default-features -E 'binary(chartgen)' → 128 tests run, 128 passed, 0 skipped. No document or SVG churn: the committed document is unchanged until the rerun, so the byte-compare has nothing to disagree with.

What this does not fix

Of the four cells that failed "consumed before assembly" at 64 KiB / 8 consumers, in-process was one and this clears it (unique_at_start 10 500 of 524 288, 2%). The other three are RabbitMQ, whose eight-consumer group assembly ran through 37 000–46 300 messages. Putting that well under half a corpus needs ~196 k messages — 12 GiB inside an 8 GB VM. Those three are a group-assembly cost, not a corpus size, and they are expected to fail again. Recorded in the script and the runbook so the rerun is not read as having fixed them.

Kafka's seven setup_bound 64 KiB rows are the same shape: they would need ~196 k messages too, which its page cache would have to hold inside the same VM.

Follow-up

This is the matrix change for CAF-889 T7. The rerun itself is on the pinned host (M4 Max, per the CAF-665 host decision), so it lands separately — scripts/bench.sh per backend in the pinned order, then scripts/bench.sh charts. Redis's consume_fifo gap closes in that same pass via #172, per the decision to leave it as published until a full rerun.

Depends-on: none — script and runbook only; the byte-cap split it builds on merged as #177, and the chart-budget headroom as #178.